Core Web Vitals y negocio: qué medir antes de rediseñar

Antes de rediseñar, mide el rendimiento de las plantillas que concentran las visitas y las conversiones. No hace falta perseguir todas las métricas de Core Web Vitals en todas las URLs. Hace falta saber si las páginas que importan aguantan el rediseño o si el sitio nuevo va a ser más lento que el que sustituye.

Core Web Vitals —LCP, INP y CLS— describen carga, respuesta y estabilidad visual. Son una parte del rendimiento, no un fin. En un sitio corporativo o B2B, una home lenta o un formulario que se mueve al cargar pesa más que un artículo de archivo con una puntuación mediocre. Este texto dice qué mirar, qué se puede aparcar y cómo escribir umbrales en un alcance sin teatro de cifras.

En resumen

• Prioriza plantillas, no el promedio del dominio: home, servicio, landing y el paso de contacto.
• Mira datos de campo si existen y una pasada de laboratorio sobre esas plantillas.
• El rediseño empeora el rendimiento cuando se suman animación, etiquetas y terceros sin un presupuesto de peso.
• En el contrato pide umbrales sobre plantillas concretas, medidos en un entorno acordado. No pidas “100 en todas las páginas”.

Medir esas plantillas es parte del desarrollo web, no un informe que llega cuando el diseño ya no se puede tocar.

Qué Core Web Vitals importan en un sitio que no es una tienda masiva

LCP mide cuándo aparece el contenido principal. En una home corporativa suele ser el bloque hero o el titular con su imagen. Si ese bloque espera a una fuente, a un vídeo o a un carrusel, el LCP se va con él.

INP mide la respuesta a la interacción. En B2B duele en menús, buscadores internos, filtros y formularios. Un sitio puede “verse” rápido y responder tarde porque el navegador está ocupado con etiquetas.

CLS mide saltos de layout. Duele cuando un banner de consentimiento, una imagen sin tamaño o un módulo inyectado empujan el botón de contacto.

Lo que rara vez mueve la decisión de negocio, por sí solo, es una puntuación mala en URLs con poco uso, o una obsesión por una centésima en una métrica de laboratorio que no coincide con lo que ven los usuarios. Úsalas para ordenar el trabajo, no como trofeo.

Un ejemplo de lectura, con números de laboratorio y sin teatro

Sirve una plantilla imaginaria, para ver el método. Home de un sitio corporativo. En laboratorio móvil, el LCP lo marca un vídeo de portada de unos cuatro megabytes que arranca solo. El texto del titular espera a dos familias tipográficas. Ahí el gestor de etiquetas carga un chat, un píxel y una herramienta de grabación de sesiones antes de que nadie haga clic. INP se resiente cuando se abre el menú, porque el chat y el menú compiten en el hilo principal. Tampoco el banner de consentimiento reserva altura y empuja el titular: hay CLS en la primera visita.

Qué se puede cambiar en esa plantilla

Ese informe no dice “la web va mal”. Dice cuatro cosas que diseño y desarrollo pueden tocar. El vídeo puede ser un póster con reproducción a petición. Una de las dos familias puede salir del sistema. La herramienta de grabación puede esperar al consentimiento, si legal está de acuerdo, y el chat puede no cargarse en la home. El banner puede ocupar su sitio desde el primer pintado. Nada de eso es una puntuación. Es una lista de cambios con un efecto esperable en esa plantilla.

Se vuelve a medir la misma URL de preproducción cuando esos cambios están en el diseño aprobado, con los terceros en el estado que tendrán en producción. Si el LCP sigue siendo el póster y el peso ha bajado, se anota el nuevo valor y ese pasa a ser el umbral de aceptación de la home. Si alguien reintroduce el vídeo automático después de esa medición, el umbral se incumple y hay que volver a decidir, no “optimizar luego”. El método es repetible en la landing y en el formulario. No hace falta repetirlo en doscientas URLs que comparten plantilla.

Cuando no hay datos de campo, el informe lo dice en la primera línea. No se inventa un percentil de usuarios reales para que el documento parezca más científico. El laboratorio ordena el trabajo. El campo, el trimestre siguiente, dirá si los usuarios ven lo mismo. Si el origen ya tiene datos en Search Console, se mira si la home está peor que el agregado. Es habitual que lo esté. El agregado lo salva el artículo cacheado que casi nadie usa para pedir una reunión.

Cómo se lee una cascada cuando el número único no dice nada

LCP, INP y CLS son tres tiempos. Cada uno se puede partir, y la parte es lo que diseño y desarrollo pueden cambiar. Quedarse en “la home saca un 62” no dice si el problema es el servidor, la imagen, la fuente o un script de terceros.

Los cuatro tramos del LCP

En LCP hay cuatro tramos. El tiempo hasta el primer byte (TTFB): servidor, TLS, distancia, HTML que espera a una base de datos o a un HTML personalizado que no se puede cachear. La demora hasta pedir el recurso del elemento LCP: el navegador todavía no sabe qué imagen es, porque llega tarde en el HTML o porque un script la inyecta. La descarga de ese recurso: peso, formato, prioridad. Y la demora de pintado cuando el recurso ya está: una fuente que bloquea el texto, un JavaScript que ocupa el hilo principal. Si el elemento LCP es un vídeo que arranca solo, casi todo el tiempo está en la descarga y en el arranque, y ningún plugin de “optimizar imágenes” lo va a mover.

Lo que se puede decidir en diseño, con esa lectura, es concreto. El elemento LCP se marca en el HTML temprano, con dimensiones (width y height, o aspect-ratio) para no empujar el layout. Si es una imagen, fetchpriority=»high» y, solo si hace falta, un preload del mismo archivo: precargar otro es competir con el que importa. El formato suele ser AVIF o WebP frente al JPEG de portada de varios megabytes. El vídeo de fondo pasa a póster y se reproduce si la persona lo pide. Las fuentes se limitan a las que de verdad se usan, con font-display decidido: swap enseña el texto antes y puede mover el layout; optional es más estable y a veces no llega a aplicar la fuente de marca. Esa elección es de diseño, informada por el tramo que duele, no un ajuste esotérico.

INP, CLS, laboratorio y campo

INP se parte en espera de entrada, procesado y presentación del siguiente frame. La espera crece cuando el hilo principal está en una tarea larga —por encima de unos 50 ms ya se nota, y varias seguidas congelan el menú o el campo del formulario—. El procesado es el propio manejador del clic. La presentación es el trabajo de estilo y layout hasta pintar. Un chat, un píxel y una herramienta de grabación de sesiones, evaluados en el arranque, producen esas tareas aunque nadie haya pulsado nada. Aplazarlos al consentimiento, o a la primera interacción en páginas donde legal lo permita, baja el INP sin tocar el aspecto. Un menú que recalcula layout leyendo posiciones en bucle hace el mismo daño desde el código propio. Se ve en el perfil de rendimiento, no en una nota global.

CLS se explica por lo que entra tarde y empuja. Imagen sin tamaño. Banner de consentimiento sin hueco reservado. Anuncio o módulo inyectado encima del titular. Fuente que cambia de métrica al cargar. La reserva de espacio se hace en el CSS del componente, no “optimizando” después. content-visibility: auto en bloques por debajo del pliegue puede ayudar al render y puede también provocar saltos si se usa sin contain-intrinsic-size. No es un interruptor mágico. Es una propiedad que se prueba en la plantilla.

Laboratorio y campo

Laboratorio y campo no se sustituyen. El laboratorio (Lighthouse o una pasada en WebPageTest, con perfil de móvil y CPU limitada, y con los terceros encendidos) sirve para diseñar: se repite, se compara la misma URL. El campo (CrUX cuando hay tráfico suficiente, o RUM si la empresa ya lo tiene) dice si los usuarios, con sus redes y sus dispositivos, caen en el mismo tramo. Un LCP bueno en laboratorio con la caché caliente y el gestor de etiquetas bloqueado no es el número que se escribe en el alcance. La cascada dice qué petición es el elemento LCP, qué tarea larga ocupa el hilo y qué respuesta no se puede cachear porque varía por cookie de sesión. Con eso, marketing puede aceptar un póster en lugar de un vídeo, y sistemas puede ver si el TTFB es de aplicación, de base de datos o de un HTML dinámico que el CDN no puede guardar.

Cómo se escribe el umbral para que compras pueda leerlo

Un umbral útil cabe en un párrafo por plantilla. Home: el elemento principal visible no será un vídeo que arranque solo; se medirá en preproducción móvil, con las etiquetas y el banner de consentimiento en el estado de producción; el valor de laboratorio que se acepte en esa medición es el que queda escrito, y una subida clara respecto a ese valor reabre la plantilla. Servicio: misma regla, con la imagen o el titular que diseño haya marcado como contenido principal. Contacto: el botón de envío no se desplaza al aparecer el banner, y el envío responde sin esperar a scripts que no son necesarios para mandar el formulario.

Lo que no cabe es “la web irá rápida” o “cumpliremos los umbrales de Google”. El primero no se puede comprobar. El segundo convierte un percentil de un buscador en una cláusula, y obliga a perseguirlo en páginas que el proyecto no va a tocar. Si hace falta citar el nombre de las métricas, se citan LCP, INP y CLS como lo que se mira, y se ata la aceptación a las plantillas de la fase. El archivo histórico puede quedar fuera sin que nadie finja que se ha medido.

El entorno de la medición

La cláusula también dice el entorno. Una medición en el portátil de diseño, con la caché caliente y sin el gestor de etiquetas, no es el entorno. El entorno es preproducción con el dominio de pruebas, los terceros acordados y una pasada en un perfil de móvil que se haya fijado al empezar. Si no se fija, cada parte traerá un número distinto y los tres serán verdad en su máquina. Sistemas y el equipo que construye dejan escrita cuál es esa máquina, porque el rendimiento sin entorno es una opinión.

Cuando el diseño aprobado incumple el párrafo, hay dos salidas y las dos se anotan. Se cambia el bloque —el vídeo pasa a póster, la segunda familia tipográfica sale, el chat no carga en la home— o se acepta un umbral peor con una frase de por qué el bloque pesa más que la métrica. La segunda salida es legítima en una campaña corta. Deja de serlo si se usa en todas las plantillas, porque entonces el umbral no existía. Marketing puede preferir el vídeo. Sistemas puede preferir el póster. El párrafo obliga a que la preferencia quede en el acta, no en un hilo que nadie relee.

El equipo que no es infraestructura sostiene el resto. Diseño propone el bloque que sustituye al que pesaba. SEO y SEM avisan si una plantilla que concentre enlaces de campaña se ha quedado fuera de la medición. Cuentas guarda el párrafo junto al alcance, para que un cambio posterior de “pongamos el vídeo otra vez” tenga con qué compararse. Sin ese archivo, el rediseño mejora el aspecto y empeora la espera, y nadie puede señalar el día en que se aceptó el cambio.

Qué no entra en esta lectura

No entra una promesa de posición en buscadores. No entra un ranking de “salud” del dominio generado por una extensión. Tampoco entra reescribir todas las imágenes del archivo histórico en la misma fase si el archivo no está en el alcance. No entra quitar una herramienta que legal o medios consideran obligatoria sin sentarlos. Si el píxel tiene que estar, se mide con el píxel. El umbral se fija con esa carga, no con una captura limpia que producción nunca va a servir.

Tampoco entra culpar al CMS. La misma plantilla puede ser ligera o pesada en WordPress, en un CMS enterprise o en un front desacoplado. El peso está en el vídeo, las fuentes, los terceros y el JavaScript propio. Cambiar de plataforma para “ganar Core Web Vitals” sin tocar esa lista es cambiar de factura, no de resultado.

La lectura baja a la arquitectura y al rendimiento: qué elemento pinta el navegador, qué script bloquea el hilo, qué se puede aplazar sin romper la medición ni el consentimiento. Marketing y sistemas aprueban el diseño con la lista delante, y el umbral que se escribe en el alcance es el de las plantillas que la gente usa.

Preguntas frecuentes

¿Hay que alcanzar el umbral “bueno” de Google en todas las páginas?

No es un objetivo de proyecto realista ni siempre útil. Empieza por las plantillas que concentran visitas y conversaciones. El archivo puede ir en una segunda fase.

¿Laboratorio o campo?

Los dos, si hay campo. El laboratorio sirve para diseñar. El campo sirve para saber si los usuarios, con sus dispositivos y sus redes, ven lo mismo.

¿El rediseño puede empeorar los vitals?

Sí, y es frecuente cuando se añade peso sin quitar el anterior. Por eso la medición de las plantillas actuales es un entregable de discovery, no un adorno.

Siguiente paso

Si el umbral está escrito, el acuerdo siguiente es qué eventos siguen existiendo el día de la publicación.

Medición y plantillas van en el mismo desarrollo web.

Siguiente en este ciclo: GA4 y el data layer en un rediseño.

Diego Quiñones · Technical Growth Architect en dobleO (Madrid). Arquitectura web, rendimiento, SEO técnico e infraestructura, junto al equipo de diseño, SEO y SEM, cuentas y dirección. Con el equipo dobleO.